CD ROM Paradise Collection 4/CD ROM Paradise Collection 4 1995 Nov.iso/program/swagd_f.zip/DATATYPE.SWG/0026_Encryption Theory.pas

Pascal/Delphi Source File | 1995-03-03 | 8KB | 142 lines

{
> I'm trying to come up with a registration keying routine for my
> software, but am at kind of a loss on how to do it and make it somewhat
> secure or a pain to crack.
> Here's a program that supposedly uses RSA encryption, but it must be for
> an older pascal because I couldn't get it to compile with version 7.0
> since it tries to use a declaration of Integer[36]. I tried it with
> just a regular Integer declaration and I couldn't get it to work (I
> think).

 OKay...  As I recall, that Integer[36] thingy was implemented on DEC
 VMS systems (possibly others) as kind of a work around for, faster than
 real, large (greater than maxint) integer math applications.  You might
 try declaring the variables as longint to test out the algorithm..
 It's 32 bit, but then it may be a hair too small even for the math
 tricks that your rsa is doing...  Making such large numbers that it
 needs 36 bit integers to avoid overflows..

   Anyway.  I was really wondering why you didn't want to implement an
 XOR type of encryption method..  It's really so much faster than any
 math trick type of implementation...As there is really no math
 involved..

 Encryption security has three basic concerns:

 It has to be secure when the enemy knows or has in possesion the method
 that you encrypted your target,
 It has to be secure when the enemy has in his possesion, your target,
 And it has to be secure if the enemy has in possesion, your method,
 your target and your key.

 Whatever the method you use, all you are really doing is changing the
 value of a byte (the simplest item) to some other value.  Or you are
 restructuring the method of access.

   Or in plain english, you compress your file, then mess it up with
 some encryption algorithm that uses a key to decrypt it.
 How you compress, and how you encrypt doesn't really matter.

   What matters, is the possible number of ways that you COULD have
 used.  If that number (of ways) is computable, then your encryption
 method is crackable.

   This number (of possible methods) is called the domain of solutions.
 If the domain of solutions can be written into a program then any
 method and combinations of methods is crackable.

   To be uncrackable, the domain of solutions must be uncomputable.
 Actually, it may very well BE crackable, but so long as it is
 uncomputable, the cracker has no way to determine where to begin
 cracking!  Thus the defence or security lies not in remaining
 uncrackable, but in remaining encrypted.  Making it take too long to
 crack.  In other words just how much time will it take to solve the
 puzzle and for how long does the puzzle have to remain unsolved before
 it is no longer relevant.

   The perfect encryption engine, would be something that has too vast
 of a number of methods to be computable, yet very simple to operate and
 use.  The answer to this seemingly paradoxical question is simple.  You
 have to introduce a non machine element into the engine.  The human
 element.  A human determined key sequence.  In other words, your key is
 defined not by position or elements, but in steps.  Or instructions on
 what to do that is not machine or engine readable.  Or in other words,
 it can't be automatic (one step) and secure.

 There are many methods, including weird math methods.  However, it has
 been shown that ALL weird math methods are no more secure than simply
 adding 1 to the value of any byte.  The proof of this was published in
 a mathamatical journal some years ago, sorry, I don't remember what it
 was..  But it basicly stated that any weird math method could be broken
 by a simple brute force program that shifted the values of varying
 lengths of bits of a small portion of the target until it found
 recognizable text or data.

 Practical concerns:
   You want a Keyed registration system.  You want to be able to send
 the registered user a post card with some instructions on it on how to
 make his program registered.  This instruction card must be unique to
 his copy of the program.  I assume that the unregistered version of the
 program will be massively distributed I.E. Shareware concept.  Simple.
 You have two maybe three steps involved.
 1 :  A uniqueness must be made in the program, something that
 identifies and connects that particular copy of the program to that
 particular registered user.  A name...
 2:  You need some method of securing the program to that particular
 registered user.  A number or code that interacts with the name to
 produce a file, or key that must then be present during operation for
 the program to work in the registered mode.
 3:  The program must be made aware that it has been registered and if
 the registration code is found to be missing, it will revert to an
 unregistered mode.

    What may happen: If the name and code is given out or stolen,
 it must not work with any other copy of the software.   This is the
 most difficult effect to produce and is not possible to implement
 without your direct involvement in the proccess.  Don't expect to be
 able to produce this effect without direct involvment.   In effect, you
 have to make a unique modification to the program unknown to the user.

 I once worked on a project that had to be totally secured in this
 manner.  The software had to be registered not only to a specific
 individual or company, but also had to be registered to a single
 machine.  We had to be absolutely sure that there were not multiple
 copies of the software executing on different machines, or indeed on
 the same machine or that there were multiple copies of the software
 that could be installed/deinstalled on the same machine.  It was a
 financial system and the possibility of using it to produce multiple
 books existed which we had to avoid at all costs.  It took a while but
 we solved the problem, unfortunately the software was never produced or
 used, as the company I created this system for went belly up before the
 project was installed and the project was cancelled.

   What we used was a regestration key file, that was modified by the
 software, so that it couldn't be used again, it couldn't be used by any
 other copy of the program.  However, if something adverse happened, the
 program knew that it was modified and the same copy of the software
 (that had been origionally registered) could use the key again.  Also,
 the key was time stamped, it was only good for a certain range of
 dates, it couldn't be used to register a copy of the program outside a
 3 day limit.   Also, the software wouldn't operate, even if it was
 registered, if it detected that the date was 30 days since it last
 operated.  It had to be in continuous use at least every 29 days for it
 to remain registered.  Remember that this was a financial package, and
 it had to remain updated to be relevant.  We also had planned to link
 to and download it's data every 30 days and provide a new key to
 operate for the next  30 days.  Thus if the software was installed, and
 the phone lines went down, or we went out of business, the software
 would refuse to operate ( in fact it would self destruct and encrypt
 all work in progress) after 30 days of no contact with home office.
 Also note that at no time did the end user ever have the key file
 before the program saw it first and got a chance to modify it.  Once
 that happened, it couldn't be used by some other copy.  Also, we
 planned on not telling the end users that the software would only work
 on one machine ( the machine it was installed on) We wanted them to
 attempt to pirate the software..
 Why?
   So that we could test their honesty as partners in the business...

   I suppose that this was somewhat mercenary on our part, but then, I
 didn't make those kinds of decisions, I just wrote the software....
}